refactor: common vitest configurations #1107

poltorak · 2025-09-05T11:15:11Z

Centralize and Standardize Vitest Configurations

What Changed

New centralized configuration system: Created testing/test-setup-config package with a factory-based approach for generating Vitest configurations
Setup presets: Introduced modular setup file presets that can be composed for different test types (unit, integration, e2e)
Simplified configuration files: Refactored 6 existing Vitest config files to use the new centralized system, reducing them from verbose configurations to simple function calls

Benefits

Eliminates duplication: Removes repetitive boilerplate across multiple vitest config files
Ensures consistency: Standardizes test configurations, coverage settings, and setup files across all packages
Improves maintainability: Changes to test configuration defaults now only need to be made in one place
Better developer experience: New configs are more readable and easier to customize with sensible defaults and preset combinations

The new system provides createUnitConfig, createIntConfig, and createE2eConfig factory functions that automatically handle common configuration patterns while still allowing customization through override parameters.

Relates to first part of #1065

nx-cloud · 2025-09-05T11:16:26Z

View your CI Pipeline Execution ↗ for commit 7008a48

Command	Status	Duration	Result
`nx code-pushup --nx-bail -- compare`	✅ Succeeded	53s	View ↗
`nx code-pushup --nx-bail --`	✅ Succeeded	1m 2s	View ↗
`nx code-pushup --nx-bail -- print-config --outp...`	✅ Succeeded	3m 48s	View ↗

☁️ Nx Cloud last updated this comment at 2025-10-06 15:34:39 UTC

pkg-pr-new · 2025-09-05T11:16:48Z

Open in StackBlitz

@code-pushup/ci

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/ci@1107

@code-pushup/cli

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/cli@1107

@code-pushup/core

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/core@1107

@code-pushup/create-cli

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/create-cli@1107

@code-pushup/models

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/models@1107

@code-pushup/nx-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/nx-plugin@1107

@code-pushup/coverage-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/coverage-plugin@1107

@code-pushup/eslint-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/eslint-plugin@1107

@code-pushup/js-packages-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/js-packages-plugin@1107

@code-pushup/jsdocs-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/jsdocs-plugin@1107

@code-pushup/lighthouse-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/lighthouse-plugin@1107

@code-pushup/typescript-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/typescript-plugin@1107

@code-pushup/utils

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/utils@1107

@code-pushup/models-transformers

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/models-transformers@1107

commit: 7008a48

github-actions · 2025-09-05T11:24:07Z

Code PushUp

🤨 Code PushUp report has both improvements and regressions – compared current commit 5a5fcfa with previous commit 33714e2.

🕵️ See full comparison in Code PushUp portal 🔍

🏷️ Categories

🏷️ Category	⭐ Previous score	⭐ Current score	🔄 Score change
Performance	🔴 36	🔴 33
Updates	🟡 84	🟡 84
Code coverage	🟡 90	🟡 90
Security	🟡 56	🟡 56	–
Accessibility	🟢 92	🟢 92	–
Best Practices	🟢 100	🟢 100	–
SEO	🟡 61	🟡 61	–
Type Safety	🟢 100	🟢 100	–
Bug prevention	🟢 100	🟢 100	–
Miscellaneous	🟢 100	🟢 100	–
Code style	🟢 100	🟢 100	–
Documentation	🔴 24	🔴 24	–

👎 3 groups regressed, 👍 4 audits improved, 👎 4 audits regressed, 14 audits changed without impacting score

🗃️ Groups

🔌 Plugin	🗃️ Group	⭐ Previous score	⭐ Current score
Lighthouse	Performance	🔴 36	🔴 33
JS Packages	NPM outdated dependencies	🟡 84	🟡 84
Code coverage	Code coverage metrics	🟡 90	🟡 90

18 other groups are unchanged.

🛡️ Audits

🔌 Plugin	🛡️ Audit	📏 Previous value	📏 Current value
Lighthouse	Total Blocking Time	🟥 1,640 ms	🟥 2,770 ms
Lighthouse	First Contentful Paint	🟥 3.3 s	🟥 3.1 s
Lighthouse	Speed Index	🟥 7.2 s	🟥 7.6 s
Code coverage	Line coverage	🟨 86.3 %	🟨 84.4 %
JS Packages	Outdated NPM dev dependencies.	🟨 59 outdated package versions (27 major, 24 minor, 8 patch)	🟨 59 outdated package versions (28 major, 23 minor, 8 patch)
Lighthouse	Time to Interactive	🟥 13.6 s	🟥 13.3 s
Code coverage	Function coverage	🟩 92.5 %	🟩 92.6 %
Code coverage	Branch coverage	🟨 85.5 %	🟨 85.5 %
Lighthouse	Avoids enormous network payloads	🟩 Total size was 2,039 KiB	🟩 Total size was 2,034 KiB
Lighthouse	Minimizes main-thread work	🟥 11.9 s	🟥 14.4 s
Lighthouse	JavaScript execution time	🟥 5.0 s	🟥 6.5 s
Lighthouse	Uses efficient cache policy on static assets	🟨 30 resources found	🟨 30 resources found
Lighthouse	Largest Contentful Paint	🟥 11.3 s	🟥 11.9 s
Lighthouse	Max Potential First Input Delay	🟥 1,390 ms	🟥 1,890 ms
Lighthouse	Metrics	🟩 100%	🟩 100%
Lighthouse	Reduce unused CSS	🟥 Potential savings of 102 KiB	🟥 Potential savings of 102 KiB
Lighthouse	Reduce unused JavaScript	🟥 Potential savings of 179 KiB	🟥 Potential savings of 180 KiB
Lighthouse	Server Backend Latencies	🟩 1,540 ms	🟩 1,400 ms
Lighthouse	Initial server response time was short	🟩 Root document took 600 ms	🟩 Root document took 470 ms
Lighthouse	Network Round Trip Times	🟩 50 ms	🟩 10 ms
Lighthouse	Remove duplicate modules in JavaScript bundles	🟥 Potential savings of 78 KiB	🟥 Potential savings of 99 KiB
JS Packages	Vulnerabilities for NPM dev dependencies.	🟥 11 vulnerabilities (1 critical, 5 moderate, 5 low)	🟥 15 vulnerabilities (1 critical, 5 moderate, 9 low)

588 other audits are unchanged.

BioPhoton

Thanks for cleaning up our test config mess :)

I left some comments.

please add a proper PR description that contains the scope and planned changes
move the config code under a Nx project in testing/vitest-setup. I updated the issue accordingly.

e2e/ci-e2e/vitest.e2e.config.ts

packages/core/vitest.unit.config.ts

packages/utils/vitest.unit.config.ts

tools/README.md

tools/vitest-config-factory.ts

BioPhoton · 2025-10-04T13:39:56Z

testing/test-setup-config/src/lib/vitest-setup-presets.unit.test.ts

+    const testTimeout =
+      kind === 'unit'
+        ? TEST_TIMEOUTS.MEDIUM
+        : kind === 'int'
+          ? TEST_TIMEOUTS.LONG
+          : TEST_TIMEOUTS.E2E;


Let's avoid conditionals in tests. It makes the test code harder to read and adds noise.

BioPhoton · 2025-10-04T13:40:17Z

testing/test-setup-config/src/lib/vitest-setup-presets.unit.test.ts

+  ['unit', setupPresets.unit.base, createUnitConfig],
+  ['int', setupPresets.int.base, createIntConfig],
+  ['e2e', setupPresets.e2e.base, createE2eConfig],
+] as const)('%s config creation', (kind, baseSetupFiles, createFn) => {


The each block for describe is introducing conditional checks in the it blocks as well as const. It further makes the tests harder to read. Let's avoid conditionals in tests as good as possible.

If you want to test basic values you could have a separate it block using the each for static things like defaults that are always the same. In the specific cases you can use expect.objectContaining to keep is focused.

see example for conditionaly

BioPhoton · 2025-10-04T13:42:51Z

testing/test-setup-config/src/lib/vitest-config-factory.ts

+export function createVitestConfig(
+  options: VitestConfigFactoryOptions,
+  overrides: VitestOverrides = {},
+): ViteUserConfig {


I suggest excluding overrides from the logic and push it to the user. This avoids complexity and reduces maintenance efforts to sync with vitest changes. WDYT @matejchalk

Please let me know which direction we should follow:

Easier override handling ( current solution ) - in this case we take care of most of the overrides but on the other hand we are exposed to vitest changes (if the happen) and we need to keep up it them

We go easy way and move transfer the "burden" of overrides to end consumer / user.

Both approaches have pros and cons. I don't feel like I'm the right person to make a decision here 😅

BioPhoton · 2025-10-04T13:44:58Z

testing/test-setup-config/src/lib/vitest-config-factory.ts

+  projectKey: string;
+  kind: TestKind;
+  projectRootUrl: URL;
+  cacheDirName: string;


you could derive the cacheDirName from the projectKey. Internally if needed you can modify if needed e.g. cache-${projectKey}.

Is it suggestion or request change 😄 ?
Deriving cacheDirName from projectKey in form: cache-${projectKey} sounds ok but makes me wonder, aren't we making some hidden bond between project key and cache directory?

Maybe we could consider cacheDirName as optional which fallbacks to cache-${projectKey} if not specified?
Let me know @BioPhoton

EDIT:
We already using such bond for coverage, let's do the same for cache. I'll update it

Maybe we could consider cacheDirName as optional which fallbacks to ...

Yes better!

cache-${projectKey} if not specified?

the "cache-" was just something to give example. In general the cache key (and directory) should be unique across the repository. That is the reason we are about it in the first place.

Method you highlighted in comment is kind of "internal", the fallback is done in line 50

Is that ok acceptable or do you suggest other approach to that?

BioPhoton · 2025-10-04T13:50:14Z

testing/test-setup-config/README.md

+### Parameters
+
+- `projectKey`: Used for cache and coverage directory naming
+- `projectRoot`: Required path/URL to the project root for resolving all paths
+- Standard Vitest configuration options can be provided in the overrides parameter


This is covered by the types. You could add TSDocs and remove it here.

BioPhoton · 2025-10-04T13:51:29Z

testing/test-setup-config/README.md

+### Defaults
+
+**Common**: `reporters: ['basic']`, `globals: true`, `environment: 'node'`, `pool: 'threads'` with `singleThread: true`, alias from tsconfig paths
+
+**Coverage**: Unit/Int enabled (reports to `<projectRoot>/packages/<project>/.coverage`), E2E disabled. Excludes `['mocks/**', '**/types.ts']`
+
+**Global setup**: Unit/Int use `['<projectRoot>/global-setup.ts']`, E2E none by default
+
+**Include patterns**: Unit `src/**/*.unit.test.*`, Int `src/**/*.int.test.*`, E2E `tests/**/*.e2e.test.*`
+
+### Setup files
+
+**Automatic inclusion**: Unit (console mocking, cleanup, UI/filesystem mocks, basic matchers), Int (console mocking, cleanup), E2E (cleanup only)
+
+**Custom setup files**: ⚠️ Specifying `setupFiles` in overrides will completely replace the defaults. To extend the default list, manually combine them with `setupPresets`:
+
+- `setupPresets.unit.{base, git, portalClient, matchersCore, matcherPath}`
+- `setupPresets.int.{base, cliui, fs, git, portalClient, matcherPath, chromePath}`
+- `setupPresets.e2e.{base}`
+


The defaults and setup files could be documented in unit tests. The example section could show the usage directly.

BioPhoton · 2025-10-04T17:56:04Z

e2e/ci-e2e/vitest.e2e.config.ts

+  },
+  {
+    test: {
+      testTimeout: 60_000,


this could be a default for the e2e target

I checked other files and there are many different values, like 20k, 40k, 80k, 60k, 120k.
Just making sure that we want to have 60k as default?

Hmmm.... I would put 20 as default. Or if there are more projects with 40 lets go with 40. And for the projects with higher or lower times go with a override.

Did not realise this is already an overwrite..

I checked that and:

Timeout Occurences

20s 6

40s 1

60s 1

80s 2

120s 1

I suggest then use 20s as default (20_000ms)

BioPhoton

Thanks for the changes! Nice testing tool! There is Readme, and tests, lovely.
I left some first comments and will wait for one feedback on the override logic for further comments.

github-actions bot assigned poltorak Sep 5, 2025

github-actions bot added 📖 Project documentation improvements or additions to the project documentation 🔬 testing writing tests 🛠️ tooling labels Sep 5, 2025

BioPhoton requested changes Sep 5, 2025

View reviewed changes

BioPhoton reviewed Sep 5, 2025

View reviewed changes

tools/vitest-config-factory.ts Outdated Show resolved Hide resolved

BioPhoton reviewed Sep 5, 2025

View reviewed changes

tools/vitest-config-factory.ts Outdated Show resolved Hide resolved

poltorak requested review from BioPhoton, hanna-skryl and matejchalk September 10, 2025 06:44

poltorak marked this pull request as ready for review September 10, 2025 06:45

BioPhoton reviewed Oct 4, 2025

View reviewed changes

BioPhoton requested changes Oct 4, 2025

View reviewed changes

Szymon.Poltorak added 8 commits October 6, 2025 17:17

feat(): create common vitest config setup

5fb5436

refactor(): wip use common vitest on few files

db63fa1

refactor(): change coverage reports directory

45055f5

refactor(): simplify vitest factory and split abstract logic

a4275cf

docs(): update new tools readme

998e8c0

test(): add unit tests for new tools

d853753

refactor(): fix circular dependency by creating new internal library

fec5f10

fix: path resolution

7b831c3

Szymon.Poltorak added 5 commits October 6, 2025 17:17

fix: path resolution #2

dd45d45

fix: path resolution #3

413f9d7

fix: path resolution #4

1f9d9a5

fix: path resolution #5

96cb4b0

refactor(testing): improve vitest config factory and test coverage

7008a48

poltorak force-pushed the refactor/vitest-configurations branch from 9433ca5 to 7008a48 Compare October 6, 2025 15:17

refactor: common vitest configurations #1107

Are you sure you want to change the base?

refactor: common vitest configurations #1107

Uh oh!

Conversation

poltorak commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Centralize and Standardize Vitest Configurations

What Changed

Benefits

Uh oh!

nx-cloud bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pkg-pr-new bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code PushUp

🏷️ Categories

🗃️ Groups

🛡️ Audits

Uh oh!

BioPhoton left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BioPhoton Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BioPhoton Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BioPhoton Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BioPhoton Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BioPhoton left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

poltorak commented Sep 5, 2025 •

edited

Loading

nx-cloud bot commented Sep 5, 2025 •

edited

Loading

pkg-pr-new bot commented Sep 5, 2025 •

edited

Loading

github-actions bot commented Sep 5, 2025 •

edited

Loading

BioPhoton left a comment •

edited

Loading

BioPhoton Oct 4, 2025 •

edited

Loading

BioPhoton Oct 6, 2025 •

edited

Loading

BioPhoton Oct 4, 2025 •

edited

Loading

BioPhoton Oct 6, 2025 •

edited

Loading

BioPhoton left a comment •

edited

Loading